Decentralised Concensus

The structure of the blockchain and the necessity for network collusion, whereby the majority of network nodes have to “vote on” (i.e. verify) blocks which contain only valid transactions that all trace back to the original block, achieves what is known as decentralised consensus. It’s this that is perhaps the most exciting feature when considered for use outside of cryptocurrency, with examples including digital voting in elections, proof of ownership for rights or other assets, and smart contracts.

It boils down to a simple rule that all nodes implicitly agree to: trust the longest chain i.e. the one with the greatest proof of work. With many miners compiling blocks and solving them, it may happen that two or more are broadcast around the network at or around the same time, and these could arrive at different nodes sooner or later than the other(s) – and all would pass verification checks. So how can you be sure that your copy of the ledger now matches that of everyone else?

Well, now some miners would be mining atop one chain, and others atop the other. Eventually, another correct block is found and broadcast whose block number is, for example, 50. It will reach some of the nodes whose block count is still 49, and they switch to 50 and broadcast 50 themselves – there is now more proof of work associated with that blockchain. The transactions in the previous competing 49 block are released ready for compiling into blocks again, no longer considered verified. In turn, any miners made aware of the new block 50 immediately disregard work put into their version of 50 and start mining their version of block 51, because even if 50 were solved it wouldn’t be accepted by any nodes aware of 50. Gradually, decentralised consensus is arrived at, and the further back your transaction is, the more you can trust it.

Now, you might attempt to defraud someone by paying for their goods or services, waiting for them to be supplied, then submitting another transaction where the original currency goes back to yourself. However, even if your victim supplies you after just one verification, you would then need to do all the work required to assemble a valid block with your fraudulent transaction in, by which point the majority of the network will likely also have added another block, reverifying the legitimate transaction. As such, you would actually need to do enough work to overtake the core chain to have your transaction verified and accepted by the majority. The more verifications your victim waits for, the harder your work becomes, and you cannot pre-compute blocks because a valid block explicitly relies on the preceding one: Changing a single bit in any block immediately invalidates that block and all that come after it in a way that every node can easily see, causing a rejection of the whole chain.

With a huge proportion of computing power, a double-spend attack like this is technically feasible, but so far no one is known to have successfully pulled one off.